1. Technical Field
This invention generally relates to object-oriented programming and more specifically relates to altering the functionality of an object.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices, and computer systems may be found in many different settings. Computer systems typically include a combination of hardware (e.g., semiconductors, circuit boards, etc.) and software (e.g., computer programs). As advances in semiconductor processing and computer architecture push the performance of the computer hardware higher, more sophisticated computer software has evolved to take advantage of the higher performance of the hardware, resulting in computer systems today that are much more powerful than just a few years ago.
Computer systems typically include operating system software that controls the basic function of the computer, and one or more software application programs that run under the control of the operating system to perform desired tasks. For example, a typical IBM Personal Computer may run the OS/2 operating system, and under the control of the OS/2 operating system, a user may execute an application program, such as a word processor. As the capabilities of computer systems have increased, the application software programs designed for high performance computer systems have become extremely powerful. Additionally, software development costs have continued to rise because more powerful and complex programs take more time, and hence more money, to produce.
One way in which the performance of application software programs has been improved while the associated development costs have been reduced is by using object-oriented programming concepts. The goal of using object-oriented programming is to create small, reusable sections of program code known as "objects" that can be quickly and easily combined and re-used to create new programs. This is similar to the idea of using the same set of building blocks again and again to create many different structures. The modular and re-usable aspects of objects will typically speed development of new programs, thereby reducing the costs associated with the development cycle. In addition, by creating and re-using a comprehensive set of well-tested objects, a more stable, uniform, and consistent approach to developing new computer programs can be achieved.
Closely connected with objects is the concept of "classes" of objects. A class is a formalized definition of a set of like objects. As such, a class can be thought of as an abstraction of the objects or as a definition of a type of object. Each object that is created in an object-oriented system is an instance of a particular class. Objects within an object oriented environment communicate and interact with each other via "method calls" or "methods" which define the relationship between objects and which specify the activities and procedures that a given object can perform.
An object in an object-oriented computer program typically has attributes defined by state data that determine how the object will behave. If an object is "transient," it is created by a process, and will terminate when the process that created it ends. If an object is "persistent," however, mechanisms are put in place to allow the object to survive the process that creates it so it can be accessed by other processes including processes that have not yet been created.
Computer programs naturally evolve over time. The evolution of object-oriented computer programs entails defining new classes that frequently have implementations different from previous versions. As time passes, the type and quantity of information stored by an object may need to be changed or enhanced to accommodate additional or different data types. In this case, the definition of the class for the object will, of necessity, be changed to support the new object data storage requirements. This typically occurs whenever a software program is upgraded from a first version to a newer, more powerful version of the program. A new release of an existing program may use a combination of new classes and existing classes that were defined in a previous version. The processes and activities associated with modifying, updating, and tracking changes in a class of objects over a period of time are known as "versioning."
When the current version of an object is going to be updated, a copy of the original object may be made. This copy is made in order to preserve the state data of the original object. The state data of this copy is created based on the state data of the original object. The copy of the original object is a new object with a new object identity. It can be understood that once a version update is performed on an object, two versions of the object exist. The original object still exists with its original state data and object identity, and the new object exists with its new object identity and new version of state data. Both of these objects are "live" in the sense that all methods can be called on them by other existing objects.
When an object-oriented system is designed, the organizational structure of the system will be based on the objectives and purposes for the system. The system will also be implemented based upon these objectives and purposes. When an object is created, it can be assumed that the objectives and purposes defined for the object allow the object to be fully functional. However, when an existing object is updated, the existing object becomes out of date because a new version of the object exists. Even thought the new object will be used in the system, in some cases it may be desirable to preserve the original version of the existing object. To ensure that the old object remains unchanged, all procedures or methods which may modify the existing object must be disabled. In order to prevent these methods from being called on an existing object, the implementation of the system must change.
In other situations, system policy may allow certain limited types of changes to be made to the original object while other, more intrusive changes may be prohibited. In order to ensure that the original object is modified only as permitted by system policy or objectives, a subset of all possible methods may need to be disabled. Only those methods which would alter the object in an unacceptable fashion must be disabled. It can be assumed that any methods which can access the original object without changing it may still be called in order to allow system users to view the data belonging to the object.
The following example may be used to demonstrate the problems encountered in calling methods on different versions of a given object. For example, in order to track annual sales figures for their products, a sales corporation may create an object in an object oriented system called "Yearly Sales." All of the objects that need to reference the Yearly Sales object will contain a pointer to the Yearly Sales object. At the end of each month, the sales data for the proceeding month is entered into the Yearly Sales object, providing a cumulative figure for the company's year-to-date sales. The corporation may also have a Purchasing Department and an Accounting Department which use an object-oriented system having an object which references the Yearly Sales object to determine how many goods to order.
For purposes of demonstrating the problems in existing object-oriented technology, it should be assumed that the Yearly Sales object has just been updated to include data for the month of June. As a result of updating the object at the end of June, two versions of the Yearly Sales object exist in the system. The old version of the Yearly Sales object contains sales data for the months of January through May and the new version of the object contains sales data for the months of January through June.
The Purchasing Department accesses the Yearly Sales object to determine how many goods to order. In deciding which clothing items to purchase, the Purchasing department checks the sales figures in the Yearly Sales object for the proceeding month. In order to procure the correct number of each item, the sales figures for the proceeding month must be accurate. Therefore, the Purchasing Department must access the old version of the Yearly Sales object to check the sales figures for the month of May. As mentioned, the Purchasing Department needs the data to be accurate, therefore the data for the month of May in the old version of the Yearly Sales object cannot be altered.
The Accounting Department, may need the data for the month of May from the old version of the Yearly Sales object to perform accounting functions. These accounting functions include the use of the data contained within the Yearly Sales object to add additional sales figures to the object, such as sales by department. Although the Accounting department needs to make changes to the old version of the object, the original sales data for the month of May will not be changed.
Since the changes made by the Accounting Department will not alter the data for the month of May, the write methods called on the Yearly Sales object by the Accounting Department will not interfere with the needs of the Purchasing Department. However, any write methods which will actually change the sales data in the Yearly Sales object from the month of May must be disabled. While it may be desirable to allow the Accounting Department and the Purchasing Department to access the Yearly Sales object, the integrity of the data contained in the Yearly Sales object may be inadvertently comprised if an existing related object updates perform an inappropriate write method on the object. In current object-oriented systems, there is no simple way to selectively disable write methods called on a given object. It is possible to reprogram or redesign the object in order to disable methods, however, this procedure must be continually repeated, adding a significant amount of overhead whenever object methods are to be disabled or reestablished. While it may be desirable to disable certain methods on an object, at the present time there is no way to accomplish this goal without requiring a programmer to modify the methods calls for a given object.
As the number of applications and systems using object-oriented technology increases, it will become increasingly important to be able to implement system objectives which may require disabling all or some write methods, and to prevent some subset of the methods from being called on an object. Without a simple and flexible mechanism for selectively disabling certain methods according to system objectives, the time and effort required to restrict access to data in different object versions will be unnecessarily expanded.